package docker

//分布式存储之哈希取余算法/节点取余法

//  1.哈希取余分区/节点取余法		//小厂

/*



------------ 1.哈希取余分区 ------------

	看图  images/docker-1001-分布式算法：哈希取余分区-01.png

	2亿条记录就是2亿个k,v，我们单机不行必须要分布式多机，
    假设有3台机器构成一个集群，用户每次读写操作都是根据公式【 hash(key)% N 】个机器台数，计算出哈希值，取余数，用来决定数据映射到哪一个节点上。

	假如有三台机器组成一个集群，用户每次读写根据公式 【hash(key)% 3】，取余，根据【余数】决定存储在那台机器
	如果余数是0，就存放redis-0，余数是1，存放与redis-1，余数是2，存放与redis-2，
	怎么存，就怎么取，存放到redis-0，取出也是从redis-0，


	比如有一亿条数据，redis-0 存三千万条，redis-1存四千万条，redis-2存三千万条
	假如3台集群突然死机redis-2，那 hash(key)% 2，丢失了三千万条数据

	优点:
		简单粗暴，直接有效，只需要预估好数据规划好节点，例如3台、8台、10台，就能保证一段时间的数据支撑。
		使用Hash算法让固定的一部分请求落到同一台服务器上，这样每台服务器固定处理一部分请求（并维护这些请求的信息），起到负载均衡+分而治之的作用。



	缺点：
		原来规划好的节点，进行扩容或者缩容就比较麻烦了额，不管扩缩，每次数据变动导致节点有变动，映射关系需要重新进行计算，在服务器个数固定不变时没有问题，如果需要弹性扩容或故障停机的情况下，原来的取模公式就会发生变化:Hash(key)3会变成Hash(key)/?。
		此时地址经过取余运算的结果将发生很大变化，根据公式获取的服务器也会变得不可控。
		某个redis机器宕机了，由于台数数量变化，会导致hash取余全部数据重新洗牌。



*/
